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que en este apartado han aparecido con la unque quienes ten- 


gan conocimientos 

versión beta de «POV 3.1». Estas novedades de programación 
no tendrán ninguna 

van a suponer una ayuda extraordinaria para dificultad en digerir 
estos artículos, hay 

los povmaníacos en general y para los muchos lectores que no se hallan en 
este caso. Por esta razón se ha procura- 

escritores de pov-ipas en particular, y por do que las explicaciones y ejemplos re- 
sultasen tan claros como fuese posible. 

ello recomendamos su aprendizaje a todos Hay que hacer hincapié, sin embargo, 
en que los experimentos propios y la 

los pov-adeptos. práctica son el único camino para do- 
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minar estas sentencias. Así pues, des- 


pués de leer los artículos (y mirar los 
ficheros de ejemplo), el lector debería 
realizar sus propias pruebas y no dejar- 
se descorazonar si comete errores 0 si 
las cosas no salen bien a la primera. Só- 
lo la práctica proporciona, en la pro- : 
gramación, la habilidad necesaria para + 
acometer diferentes proyectos comple- ; 
jos. Dichas sentencias son ES, 
mente imprescindible del 


1) Crear más fácilme 


Rand, Seed y otra si . 


En el núm DN Y A 
E 


sólo unas pocas líneas en el fichero es 
cénico. Esta sentencia es las 


escenas de batallas medievales e: 


orcos y humanos que se aid 


el número 17 de Rendermanía (y de 
otras muchas imágenes). Sin embargo, 
el uso de H+while por sí solo será insufi- 
ciente en ciertos casos. Supongamos, 
por ejemplo, que deseamos crear una 
escena en la que hay un regimiento de 
caballeros medievales. Podemos crear 
dicho regimiento utilizando un doble 
bucle while anidado de la manera que 
vimos en el artículo anterior. De esta 
forma podremos crear una formación 
con un número cualquiera de filas y co- 


| 
ÍA 


lumnas. El problema es que el efecto 
esultante será de una perfección exce- 
siva: todos los caballeros estarán ali- 
neados formando un cuadro tan perfec- 
to que la escena no resultará demasiado 
creíble. Pero, afortunadamente, pode- 
mos resolver este problema empleando 
las funciones rand y seed. 

¿Que de dónde salen estas funcio- 
5? «POV> dispone de una serie de 


ara manipular valores € 


línea sería un ejemplo válido 
de uso de seed 


guiente 


Hdeclare Rl=seed(16384); 


Con esta línea estaremos abriendo 
un canal llamado R1 para utilizar el ge- 
nerador de números pseudoaleatorios 
de «POV». Después de esto, cada vez 
que invoquemos a rand dándole R1 co- 
mo parámetro, esta función nos devol- 


Utilizando rotate podemos situar los galeones 
sobre un mundo de cualquier tamano. 


rand, 


: prend 


LA esto? Co- 


s aclarando que un genera- 


dor de números pseudoaleatorios es un 


Et goritmo que emplea una fórmula da- 


da para producir una larga secuencia de 
números. Estos números son, aparen- 
temente, aleatorios, pero en realidad es 
fácil producir la secuencia si conoce- 
mos la fórmula que se está empleando. 
El algoritmo acepta un valor como se- 
milla y este valor se emplea para deci- 
dir el punto de la secuencia desde don- 
de rand empezará a devolver valores al 
usuario. Esto quiere decir que una se- 
milla dada producirá siempre la misma 


Ejemplos del uso de rand 


object[ttinclude “soldado.inc” texture([ pielorco)] 


Hdeclare alto=.8 + rand(R)*.25: 
fdeclare ancho=.90 + rand(R)*.2; 
scale <l *ancho, | *alto, I*ancho> 
Hdeclare sumx=tand(R)*30: 
tídeclare sumz=rand(R)*30; 


translate <Xbase+xpos+sumkx, 0, Zbase+zpos+sumz> 


secuencia de números. En fin, volvien- 
do al ejemplo del regimiento, echad un 
vistazo a la Figura l. 

Este ejemplo está tomado de uno de 
los ficheros utilizados para las escenas 
de batallas, y en él la sentencia object 
empleada está incluida dentro del bu- 
cle while doble empleado para cons- 
truir un regimiento. Las variables Xba- 
se, xpos, Zbase y zpos se han empleado 
para situar a cada soldado dentro de su 
posición ideal dentro del cuadro. Pero 
aquí no nos interesa cómo se han cal- 
culado estas variables. Sólo nos intere- 
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Figura 1 
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tideclare R1 =seed(16384); 
Hdeclare R2 = seed(12345); 


sphere [ <rand(R1), rand(R1), rand(Rl )>, rand(R2) ] 


sa saber que SUMmx y Sumz 
son variaciones aleatorias 
que se suman a la posición 
ideal de cada soldado, para 
conseguir que la formación 
no resulte excesivamente 
perfecta. Tomad nota de que el valor 
devuelto por rand sigue estando entre 
O y 1 pero, al multiplicarlo por 30, con- 
seguimos que los valores para sumx y 
sumz oscilen entre O y 30 unidades. 
Además. hemos empleado rand para 
crear pequeñas variaciones aleatorias 
en la estatura y el ancho de cada solda- 
do. Para la estatura, por ejemplo, se 
multiplica el valor devuelto por rand 
por 0.25 (con lo que éste oscilará entre 
O y 0.25) y luego se le suma el valor 
0.8. Con ello el valor resultante estará 


siempre comprendido entre 0.8 y 1.05. 


Cuadro! 


De esta forma, en la sentencia denomi- 
nada scale, la altura del personaje se 
multiplicará por la variable alto, con lo 
que el personaje encogerá o crecerá se- 
gún el valor de esta variable. 

Por otro lado. puede suceder que el 
usuario desee emplear varias semillas 
simultáneamente y por esta razón, en 
«POV», el generador funciona a través 
de “canales”. En el manual tenemos el 
ejemplo representado en el Cuadro 1. 

Con estas líneas se crea una esfera 
cuya posición en los ejes X.Y y Z se 
define con los valores devueltos por 
rand con el canal R1. En cambio, el ra- 
dio de la esfera depende del valor de- 
vuelto mediante el canal R2. Pero ¿pa- 
ra qué puede servirnos el emplear más 
de un canal para el generador? Si- 
guiendo con el ejemplo del regimien- 
to, imaginemos que se ha empleado 
rand para definir las posiciones de cada 
soldado y para dar valores de rotación 
aleatorios a los brazos y piernas de ca- 
da modelo, definiendo así una postura 
distinta para cada uno (cosa que ya he- 
mos hecho en números anteriores). Es- 
tá claro que. como cada semilla produ- 
ce siempre la misma secuencia de 
números, una misma semilla produci- 
rá siempre la misma escena. Pero ahora 
supongamos que decidimos, además, 
utilizar rand para crear leves variacio- 
nes en la pigmentación de la armadura 
de cada soldado (haciendo sumas alea- 
torias en los valores originales de rgb 
de cada uno). Si empleamos un sólo ca- 
nal para todo esto, el regimiento que 
obtendremos será distinto. ¿Por qué? 
Porque los valores devueltos por rand, 
y que antes sólo se empleaban en la po- 
sición y rotación de los modelos, se 
emplearán ahora también para alterar 


el color de éstos. Así pues, como ahora 
cada soldado necesitará más valores 
rand, a partir del segundo soldado la se- 
cuencia de valores rand devueltos esta- 
rá desplazada con respecto a la escena 
anterior. Obtendremos, así, valores dis- 
tintos para las variaciones aleatorias de 
posición y escalado y también para la 
definición de posturas, y por ello la 
nueva escena será completamente dis- 
tinta a la anterior. Sin embargo, si dese- 
amos generar la misma escena de an- 
tes (salvo por los cambios en el color), 
podremos hacerlo utilizando el mismo 
canal de antes para las tareas de varia- 
ción posicional y definición de postu- 
ras, al tiempo que empleamos otro nue- 
vo que sólo será referenciado por rand 
en las cuestiones de variación del color 
de las armaduras. 

Resumiendo, las funciones rand y 
seed pueden ser empleadas para produ- 
cir variaciones posicionales. de escala. 
de orientación, de cambios de color, y 
de elección de modelos, por citar sólo 
algunas de sus posibilidades. 


Más funciones flotantes 

A continuación, señalaremos algu- 
nas de las funciones que tratan valo- 
res en flotante y que se utilizan con 
mayor frecuencia: 


Hemos utilizado un arrray para crear la 
formación de la flota (sl=:1, hay barco) 


abs(A): Retorna el valor absoluto de 
la variable A. Si A era negativa, el valor 
devuelto lo será también. 

ase(S): Devuelve un valor entero 
comprendido entre O y 255. Este valor 
es el que corresponde al primer carác- 
ter ASCII de la cadena S dada como 
entrada. Por ejemplo asc(“ABC”) de- 
vuelve 65 por “A”. 

ceil(A): Retorna el entero más pe- 
queño mayor que Á. 

cos(A): Retorna el coseno de A. 
Tanto A como el valor devuelto se dan 
en radianes. 

degrees(A): Devuelve en grados el 
valor de A (que estaba en radianes). 

div(A/B): Retorna la parte entera 
de A/B. 

floor(A): Devuelve el mayor entero 
menor que A. 


resto después de la división. 
radians(A): Convierte un va- 
lor dado en grados a radianes. 
sin(A): Devuelve el seno del 
ángulo A. 
tan(A): Devuelve la tangente 
del ángulo A. 
val(S): Retorna el valor en 
flotante correspondiente a la 
cadena suministrada. Por 
ejemplo val(““1234.56”), nos 
devolverá el valor 1234.56. 
Existen algunos casos en los que es 
indispensable el uso de algunas de es- 
tas funciones. Por ejemplo, suponga- 
mos que hemos creado tres modelos di- 
ferentes de casas y deseamos generar 
un pueblo alternando las casas aleato- 
riamente. Para lograr la escena pode- 
mos utilizar un doble bucle para posi- 
cionar las casas y ala función seed para 
alterar un poco la colocación. También 
podemos utilizar rand para decidir qué 
casa poner antes de escribir la senten- 
cia object. Ahora bien, hay que recor- 
dar que rand siempre devuelve valores 
en flotante entre O y !. ¿Cómo pode- 
mos escribir esto? Una posible solu- 
ción la podemos encontrar en el trozo 
de código indicado en la Figura 2. 
Como puede verse en este ejemplo, int 


int(A): Trunca la parte 
decimal de A y devuelve 
sólo el valor entero. 

max(A,B): Retorna 
A o B dependiendo de 
cuál de los dos tenga el 
mayor valor. 

min(A,B): Devuelve A 
o B según cuál de los dos 
sea el valor menor. 

mod(A/B): Retorna el 
modulo de A/B, o sea el 


Uso de rand e int para elegir objetos aleatoriamente 


tideclare cual=int(rand(S)*3); 
Hf (cual=0) 

object[casal translate<posx, posy, posz>] 
Htend 
Hfif (cual=D) 

object[casa2 translate<posx, posy, pnsz>)] 
end 
Hif (cual=2) 

object(casa3 translate<posx, posy, posz>| 
ttend 


Figura 2 


trunca la parte decimal del valor de- 
vuelto por rand, con lo que la variable 
“cual” valdrá siempre 0, l 0 2. Por su- 
puesto, también podríamos evitar el 
uso de int y cambiar las condiciones 
escritas en los Hifs, pero, tal y como 
está, el código resulta más sencillo de 
leer. El resultado, no obstante, no es 
demasiado elegante y lo sería aún me- 
nos si tuviéramos 20 modelos de casa 
entre los que elegir. En este caso po- 
dríamos escribir 20 Hifs, pero sería 
mucho mejor utilizar otra sentencia 
condicional: switch. 


FSWITCH 


En la Figura 3 tenemos un ejemplo 
de cómo podríamos utilizar switch en 
el caso del ejemplo de las 20 casas. En 
primer lugar, debemos situar la senten- 
cia en el centro del doble bucle ++while 
(o de cualquiera que sea el trozo de có- 
digo que estemos empleando para dar 
valores a las variables de posición de 
los objetos). Posteriormente, observad 


Ejemplo de uso de Hswitch 
y sus sentencias asociadas” 


tideclare cual=intirand(S)*40); 

+switch (cual) 
Hicase (0) 
object[casal translate<posx, posy, posz>| 
tíbreak 
Hcase (1) 
object[casa2 translate<posx, posy, posz>| 
Hbreak 


Htrange(20,30) 


object[casal9 translate<posx, posy, posz>]) 


Hbreak 
ttelse 


object(casa20 translate<posx. posy, posz>) 


Htend 


Figura 3 


6 Rendermanía 


Taller Virtual 


la primera sentencia del ejemplo. 
Como véis, el valor que multiplica al 
devuelto por la función rand no es 20 
sino 40. ¿Por qué? Porque hemos deci- 
dido complicar un poco el ejemplo de 
las 20 casas. En efecto, seguimos te- 
niendo 20 modelos de casas, pero aho- 
ra queremos que dos de ellas se utili- 
cen con más frecuencia en la 
construcción del pueblo. Veamos cómo 
funciona esto. En primer lugar debe- 
mos colocar la variable “cual” dentro 
de los paréntesis que siguen a la sen- 
tencia fswitch. Así, esta variable será 
empleada para estudiar las condiciones 
de la sentencia. El primer ejemplo de 
esto lo tenemos en la siguiente línea. 
En ella se abre con ftcase un caso que 
se cumplirá si el valor de la variable 
“cual” corresponde al que hay indica- 
do entre los paréntesis del Hcase. Si se 
cumple este caso, entonces se compi- 
larán todas las sentencias que haya- 
mos escrito entre el Htcase y la senten- 
cia Hfbreak. (En cuanto a la función de 
esta última, su propósito es, por 
supuesto, marcar el final del 
bloque de sentencias abierto 
con la sentencia tcase). Así 
pues, si “cual” es igual a 0, se 
creará el objeto casal y. al en- 
contrar el Hbreak. POV saltará 
al final de la sentencia switch 
(dicho final está marcado por la 
sentencia Hend, tal y como su- 
cede con Hif y ftwhile). 

Naturalmente, en caso de que 
“Cual” valiese 1, las sentencias 
de este primer caso no se com- 
pilarían, haciéndolo en su lugar 
las incluidas dentro del bloque 
delimitado por el segundo +fca- 
se (con lo que se crearía el obje- 
to casa2). Podemos escribir tan- 


tos bloques case como queramos den- 
tro de una sentencia switch, y dentro 
de cada bloque +tcase puede haber tan- 
tas sentencias como sea preciso (inclu- 
so podemos tener dentro otras senten- 
cias Hswitch, largos bucles +twhile, 
macros, o lo que sea). Sin embargo, y 
en aras de la claridad. no es recomen- 
dable que estos bloques sean excesiva- 
mente largos. Además, hay que recor- 
dar que dentro de los paréntesis de las 
sentencias ficase deberemos escribir 
siempre constantes o valores numéri- 
cos, nunca variables. 

Ahora veamos cómo funcionan otras 
dos sentencias asociadas a Hswitch. La 
primera de ellas es Hrange y se emplea 
para indicar que el bloque de senten- 
cias delimitado por ella misma y por 
break se compilará sólo si el valor da- 
do al switch está comprendido entre 
los dos valores indicados entre los pa- 
réntesis de Frange o es igual a alguno 
de dichos valores. En el ejemplo, estos 
dos valores (que deben estar separados 
por una coma) son 20 y 30, de manera 
que, como los posibles valores dados a 
“cual” estarán siempre entre O y 39, es- 
to quiere decir que aproximadamente 
una de cada cuatro casas del pueblo se- 
rán del modelo casal9. 

Por último, tenemos el caso del +telse 
que, como ya vimos con la sentencia 
Hif, puede traducirse literalmente como 
“y si no...”. Cuando «POV>» encuentre 
esta sentencia en el lugar de fcase o 
firange, entonces se compilará su blo- 
que de sentencias si ninguno de los ca- 
sos expuestos por las sentencias Hcase 
o firange se cumple. 

Resumiendo, +switch es una senten- 
cia de decisión utilizada para casos de 
ramificaciones múltiples en los que el 
uso de Hif, aunque posible, es desacon- 


/ 


En la portada del número 0 se utilizó un ¿switch con unos 28 
cases que test l valor devuelto por rand para cada casa. 
e 


sejable debido a la dificultad de lectu- 
ra que comportaría la escritura de mu- 
chos +tifs encadenados. Por otro lado, 
con switch sólo podemos establecer 
comparaciones de igualdad con la va- 
riable escrita entre los paréntesis de la 
sentencia (salvo por el uso de ffrange). 
Con +fif, en cambio, podemos estable- 
cer condiciones mucho más complica- 
das. Un buen ejemplo de *switch fue 
la portada del primer número de Ren- 
dermanía, donde se utilizó esta sen- 
tencia para crear (empleando, tam- 
bién, fwhile y rand) un pueblo con 
diferentes casas medievales. 


Arrays 
Hasta ahora todas las sentencias de 
“programación” explicadas son las que 


aparecieron con «POV 3.0». A partir de 
este momento, comenzaremos a estu- 
diar las que añade la nueva versión 3.1. 
Una de ellas es array, una sentencia que 
sirve para definir estructuras de datos 
que se conocen precisamente con ese 
nombre: arrays. (Otros nombres menos 
utilizados son arreglos, matrices y ta- 
blas). De nuevo este nombre significará 
mucho para cualquier programador y 
efectivamente los arrays de POV 3.1 se 
parecen bastante a los del lenguaje C. 
Pero, ¿qué es un array? 

Un array es una agrupación de varia- 
bles del mismo tipo a las que se llama 
por un mismo nombre. Se accede a ca- 
da elemento del array especificando el 
nombre del array y añadiendo un índice 
a dicho nombre. Veamos un ejemplo 


sencillo de cómo se crea un array: 
tídeclare misdatos = array[ 10] 


Esta sentencia crea el array de una 
sola dimensión llamado misdatos que 
consta de diez elementos. El primer 
elemento de un array de este tipo se re- 
ferencia siempre con el valor O para su 
índice, por lo que es fácil imaginar que, 
en este caso, el último elemento de 
nuestro array será referenciado con el 
valor 9. Así, la sentencia: 


tideclare misdatos[0]=56 


guarda el valor 56 en el primer ele- 
mento de la tabla mientras que la si- 
guiente sentencia: 


tHideclare yuyu=misdatos[0] 


copiará el valor 56 guardado en este 
elemento en la variable yuyu. 

Ahora conviene hacer unas puntuali- 
zaciones. Á diferencia de como sucede 
con los arrays del lenguaje C, en 
«POV>» podemos crear un array sin in- 
dicar el tipo de datos que va a guardar. 
Esto es lo que hemos hecho al crear el 
array misdatos. Sin embargo, en cuanto 
asignemos un tipo de dato a cualquier 
elemento del array, todos los demás só- 
lo podrán guardar ese tipo de dato. En 
el caso anterior hemos asignado un va- 
lor numérico al primer elemento del 
array, por lo que POV nos dará un error 
(y dejará de compilar) si intentamos 
asignar (por ejemplo) una textura a otro 
elemento del mismo. Ahora bien. esto 
nos conduce a una sencilla pregunta; 
¿Qué tipo de datos podemos guardar en 
los arrays de «POV»? Pues sencilla- 
mente cualquier cosa que pueda ser 


Algunos ejemplos de uso de arrays 
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1lejemplo 1: las siguientes lineas no crean ningun objeto 


tideclare misdatos = array[ 10] 
tideclare misdatos[5] = 57; 


Ma siguiente sentencia falla porque ya se ha establecido que misdatos va a guardar valores numericos 


tideclare misdatos[0)=pigment(White) 


/lesta sentencia provoca un fallo de compilación 


TILa sentencia que sigue tambien dara error porque el elemento misdatos[4] aun no ha sido inicializado 


Htdeclare bill = misdatos[4]; 
tideclare misdatos[3]=misdatos[5H4-92; 


//en cambio esta sentencia funcionara 


ejemplo 2: crea una esfera blanca sobre fondo verde 


iideclare colorines = array[3](White, Red, Green] 


iideclare tpruebal=texture[ pigment[ colorines[0]) finish[F_MetalA]) 
tideclare tprueba2=texture (tpruebal finish[ambient 0.16)) 


sphere(<0.20,0>,20 texture (tpruebal ) ) 
plane(y.0 pigment!colorines[2]) 


Tfejemplo 3: crea una esfera roja sobre un plano verde 


tídeclare colorines = array[3][ White, Red, Green) 


tídeclare tprueba l=texture (pigment[colorines[0]) finish(F_MetalA)) 


tídeclare yuyu=array[2] 


ttdeclare yuyu[O]=sphere(<0,20,0>,20 texture(tpruebal )) 


itdeclare yuyu[ I]=plane(y,0 pigment(colorines[2])) 


object[yuyu[O] pigment(Red]) 
object[yuyu[1]) 


asignada con una sentencia tdeclare. 
Así pues, aparte de valores numéricos, 
podemos usar arrays para guardar vec- 
tores, colores, normales, acabados, de- 
finiciones completas de texturas e in- 
cluso objetos. 

Por otro lado, como el usar senten- 
cias declare para inicializar cada ele- 
mento de un array sería algo bastante 
pesado, «POV» nos ofrece otra forma 
de hacerlo. Por ejemplo. la siguiente 
sentencia nos servirá para inicializar 
todos los elementos de misdatos al 
mismo tiempo que creamos este array. 


misdatos=array[10](57,1,2,3,4,5,8342,45,0,12) 


Con esto, misdatos[0] guardará el 
valor 57, misdatos[1] guardará el valor 
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Figura 4 


| y así sucesivamente. Este mismo sis- 
tema se puede utilizar con otros tipos 
de datos. Por ejemplo, con colores: 


misdatos=array[3](Red, White. Green) 


Naturalmente, para que este último 
array sea válido, los identificadores 
de los colores habrán de estar iniciali- 
zados (lo que podemos hacer cargan- 
do previamente el fichero colors.inc). 
Ahora echad un vistazo a la Figura 4 
donde hemos puesto algunos ejem- 
plos correctos e incorrectos de crea- 
ción y uso de arrays. 

En el primer ejemplo, la asignación 
de un dato de tipo pigmento a un ele- 
mento de un array en el que ya se había 
asignado un valor numérico provoca un 


error. (De hecho, esta línea provoca un 
cuelgue de POV en la versión beta con 
la que se han realizado estas pruebas. 
Es de suponer que esto no sucederá en 
la versión definitiva). La asignación a 
la variable bill también falla porque el 
elemento misdatos[4] está sin iniciali- 
zar. En cambio, la asignación del valor 
para misdatos[3] funciona. 

El ejemplo 2 es un poco más comple- 
jo. Primero se define un array de colores 
y luego se usa uno de los elementos de 
dicho array en la asignación del pig- 
mento de la textura tpruebal. Luego, a 
su vez, esta textura es utilizada normal- 
mente dentro de la declaración de un 
objeto -una esfera- mientras que otro 
elemento del array es empleado directa- 
mente como pigmento dentro del objeto 
plane. Este ejemplo se renderizará sin 
fallos y su resultado será una esfera 
blanca situada sobre un plano verde. 


Hasta ahora creátlamos estas 
= formaciones con bucles dobles 
(fhwhlle) pero el uso del array 

nos da mayor flexibilidad. 


Y por último tenemos un tercer 
ejemplo que es un pequeño refina- 
miento sobre el anterior. Como antes, 
se crea un array de colores y se usa uno 
de sus elementos -el cero. que tiene 
asignado el color blanco- para declarar 
la textura tpruebal. Luego se declara 
un nuevo array llamado yuyu y se le 
asigna como primer elemento una es- 
fera sobre la que se aplica la textura 
tprueba!. Después se inicializa el si- 
guiente elemento de este array. asig- 
nándole un plano sobre el que se aplica 
como pigmento otro de los elementos 
del array de colores. Por último, crea- 
mos los dos objetos del array yuyu, pa- 
ra lo cual únicamente tenemos que re- 
ferenciar a estos dos elementos desde 
dentro de sendas sentencias object. Es- 
te ejemplo también compilará sin fallos 
y el resultado será una esfera roja so- 
bre un plano verde. (Nota: si queréis 


comprobar el funcionamiento de estos 
ejemplos —que se hallan en el fichero 
arraypru.pov— debéis probarlos uno a 
uno, desconectando —con comentarios— 
todos los demás en cada prueba). La 
esfera es roja porque aunque yuyul[O] 
es una esfera blanca, el pigmento del 
objeto ha sido sustituido por otro al in- 
vocar a dicho objeto. 

En resumen, recordad que: 

1) Una vez que se asigna un elemen- 
to de un tipo dado a un array. todos sus 
demás elementos deben de ser del mis- 
mo tipo. 

2) En un array cualquiera, no debe- 
mos referenciar elementos que no han 
sido imictalizados. 

3) Para emplear los elementos de un 
array, debemos referenciar a dichos 
elementos desde los mismos puntos 
en los que hubiéramos escrito el tipo 
de dato que contienen. Si el array 
guarda colores, desde dentro de un 
pigmento, si guarda texturas, desde 
dentro de una sentencia texture, si 
guarda objetos, desde dentro de una 
sentencia object, etcétera. 


Arrays de más 
de una dimensión 

Hasta ahora todos nuestros ejemplos 
han sido arrays de una dimensión. Es- 
tos son, como hemos visto, listas de da- 
tos que se guardan en posiciones conti- 
guas de memoria, en orden creciente (0 
para el índice al primer elemento, l pa- 
ra el segundo, etc.). Pero «POV» per- 
mite utilizar arrays multidimensionales 
de hasta un límite de cinco dimensio- 
nes, de los cuales el caso más sencillo 
es el del array de dos dimensiones. Un 
array de este tipo puede definirse como 
un array de arrays de una dimensión y 
su formato queda así: 


tideclare nombre_array=array[tamaño_primera 


_dimensión][tamaño_segunda_dimensión] 


Así pues. para declarar el array bidi- 
mensional yuyu de tamaño 4*3, escri- 
biríamos: 


tídeclare yuyu=array[4][3]: 


En cambio, para asignar un valor al 
primer elemento del array tendríamos 
que hacer lo siguiente: 


ttdeclare yuyu[0][0]=46; 


Como puede verse, en estos arrays 
se utilizan dos índices para definir su 
tamaño y acceder a sus elementos. Los 
arrays bidimensionales se almacenan 
en matrices en las que el primer índice 
indica la fila y el segundo la columna. 
En la memoria del ordenador esto se 
almacena de forma que primero van las 
columnas y luego las filas. Se comien- 
za, pues, con el elemento O de la pri- 
mera columna, se continúa con el O de 
la siguiente y así hasta que se pasa a la 
primera columna de la siguiente fila. 
Esto es, el orden de almacenamiento 
hace que el índice de la derecha vaya 
cambiando más deprisa que el prime- 
ro. Por otro lado, estos arrays pueden 
inicializarse también en el momento de 
ser creados, aunque el formato cambia 
un poco con recpecto a los arrays uni- 
dimensionales. Examinad la Figura 5. 

En este ejemplo, el elemento [0][0] 
del array es inicializado con el valor 7, 
el [0][1] lo hace con el valor 6 y el 
10112] lo hace con el valor 4. Después, 
los siguientes elementos (si seguimos 
el orden de almacenamiento) serían el 
[1JTO] (que vale 1), el [1][1] (que vale 
2), el [1112] (que vale 3), etc. Obsérve- 


Declaración de un array bidimenslonal 


Taller Virtual 


/fasí pueden declararse el array yuyu de 4*3 elementos 


Hideclare yuyu=array[4][3] 
[ 
17,6,4), 
(1.2.3). 
(0,9,8), 
(4,5,5) 


Figura 5 


se que en la creación de un array ini- 
cializado de este tipo hay que emplear 
comas para separar los diferentes ele- 
mentos y las dimensiones (que se deli- 
mitan con llaves). 

Los arrays de tres o más dimensio- 
nes, no suelen se utilizan muy amenu- 
do, porque la cantidad de memoria que 
requieren crece de una forma exponen- 
cial con cada nueva dimensión. 

Así por ejemplo, en el siguiente array 
reserva espacio para 4*6*8 elementos. 


tfdeclare yuyu=array[4][6][8] 


Posibles usos 
de los Arrays 

Aunque llevamos ya un 
buen rato hablando de arrays, 
aún no hemos dicho nada so- 
bre su utilidad, de modo que 
vamos a reseñar una serie de 
posibles usos. Por supuesto, 
solo vamos a mencionar unos 
pocos ejemplos y será la prác- 
tica, en el futuro, la que nos permitirá 
hallar muchos más usos para esta 
nueva característica de «POV». 

1) Suponed que hemos escrito un 
array bidimensional de valores numé- 
ricos donde cada número correspon- 
de a la altura Y de un vértice de un 
objeto, el cual se usará como suelo en 
una escena en la que vamos a colocar 
personajes antropomórficos. Podría- 
mos, entonces, al situar a cada perso- 
naje en dicho suelo, determinar el ele- 
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mento de altura que le corres- 
ponde y asegurarnos que man- 
tiene los pies en el suelo, sin 
que importen las irregularida- 
des del mismo. ¡Se acabaron 
los suelos planos! 

2) Imaginad que tenemos una 
superficie plana de forma irregular, co- 
mo por ejemplo la cubierta de un bu- 
que de principios del siglo XIX. Que- 
remos situar una serie de modelos en 
esta superficie de manera que no se su- 
perpongan unos y otros. Como dicha 
cubierta no tiene forma rectangular se- 
ría difícil, o imposible, utilizar while 
para hallar los valores de posición de 
los modelos. Por ello, en vez de esto, 
podemos crear una gran matriz bidi- 
mensional para guardar valores numé- 
ricos que indiquen la distribución de 
los modelos sobre la cubierta. Un va- 
lor O podría significar ningún modelo, 


un valor 1 el modelo tal en tal postu- 
ra, un valor de 2 otro modelo en otra 
postura, etc. Podríamos usar un doble 
bucle para leer el array y sería senci- 
llo calcular la situación de cada mo- 
delo según la posición del valor leído 
en la matriz. (Según el tamaño de la 
superficie, podemos suponer que cada 
elemento esta a 50 unidades de los 
elementos adyacentes o a 300 o a 
10000 unidades, según sea el caso). 
3) Podemos usar un array para guar- 
dar listas de texturas y objetos simples 
y crear con ello un Pov-¡pas de crea- 
ción de árboles o de edificios o de lo 
que nos apetezca, con más facilidad. 
4) Podemos guardar datos numéri- 
cos que se utilizarán en animaciones 
como trayectorias complejas de obje- 
tos, rotaciones, cambios de escala, 
cambios de cámara. etc. 
En fin, se nos acabó el espacio. El 
mes que viene continuaremos tra- 
tando estas sentencias. 


En estas pruebas -y en la propla portada-, se 
empleó el soldado de Óscar Alvárez Díaz, 


Realizar animaciones 
con POV 3.1 (parte 1) 


E] 


Crear animación por ordenador puede ser una tarea larga y tediosa, 


pero la recompensa merece la pena. A lo largo de los últimos meses se 
han recibido numerosas cartas de lectores que preguntaban cuándo se 
iba a tratar este tema. Coincidiendo con la presentación de la cuarta 
beta de «POV 3.1»,- este mes estudiaremos cómo pueden crearse 


películas de animación sintética con «POV», 
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Cóm0O... 


rear animaciones entre los amantes de «POV» y por ello 


con «POV» es una pronto empezaron a aparecer utilida- ; 
des de todo tipo para apoyar a los crea- ¿ 


dores de animaciones. 


tarea que presenta 
ciertas dificultades 
y ello se debe a que La situación mejoró bastante con la: 
nuestro raytracer fa- aparición de la versión 3.0 de «POV». ¿ 
vorito no fue diseñado pensando en la ya que dicha versión implementaba 
creación de películas sintéticas. Para muchas'sentencias de “programación” 


empezar, «POV» no dispone de un en- que podían ser empleadas en la gene- 


torno integrado de ventanas en donde ración de animaciones. Sinembargo, es 
posible que la verdaderarevolución en 
este apartado se désahora;,con lapubli- 
cación de la,versión 3.1 de «POV»; 


¿Por qué? Porque esta última versión 


puedan definirse paths demovimiento 
para los modelos ola cámara. Además, 
«POV» no produce-una salida en 
formato FLIFELC o AVI para que po- 
damos admirar 


a animación in= : aporta nuevas sentencias de “progra= 


mediatamente, De hecho, hasta la-apa- mación” que hacen innecesario el uso 


rición de la versión. 3:0, lo único que de algunas utilidades de apoyo que has- 


«POV» podía ofrecer para-ayudar al ta ahora eran imprescindibles. En efec- 


sufrido creador de.animaciones era to, empleando sentencias como +if, 
switch, array, fmacro y otras, podre- 


mos programar ciertas animaciones : 


una Variable interna llamada clock (re- 


loj), cuyo.funcionamiento estudiare- 


mos más adelante. Sin embargo, aun 
así. «POV» ha sido utilizado para ge- a 
ner: animaciones casi desde su pri- 
mera versión. Esto fue posible debido 
a que había.muchos programadores 


que resultarían difíciles de generar in- : 
cluso mediante el uso de programas ¿ 
con entornos visuales. El inconvenien- 
¿ te, por supuesto, es que al tratarse de ¿ 
3 sentencias nuevas no hay, por ahora, E 


r 


AMIA IOWA 
'N Y Y 'N uN 


Fichero de ejemplo Pentmap 


ejemplos de creación de animaciones 
que empleen estas ventajas, ni tampo- 
co demasiada documentación sobre el 
tema. (Lo mismo sucede con muchos 
pov-ipas que tendrán que ser actuali- 
zados para que puedan ser empleados 
con «POV 3.1»). Esto implica que 
tendremos que investigar muchas co- 
Sas por nosotros mismos si queremos 
prescindir del uso de conceptos y uti- 
lidades queen este momento ya se 
hallan anticuadas. 

Todo esto no quiere decir. no obs- 
tante, que la animación con «POV» se 
haya convertido de repente en pan.co- 
mido. Crear animaciones siguesiendo, 
con «POV>» o cualquier otro programa, 
una tarea lenta.y dura que €n.ocasio- 
nes puede calificarse de auténtico 
suplicio, Y si que cos consegujf bue- 
nos resultados el camino seguira pa- 
sando —como siempre— por brutales 
exprimimientos neuronales, por doce- 
nas y docenas de,pruebas, y«por días, 
semanas e ineluso meses de lentos cál* 
culos para nuestras CPU. La única ma- 
nera de minimizar nuestros esfuerzos 
estará en un sólido dominio de loscón- 
feptos básicos del funcionamiento de 
«POV> y en una cuidadosa planifica- 
ción del trabajo antes de.empezar a ge- 
nerar un solo frame. 


Cifras básicas 

Como todo el mundo sabe. cuando 
estamos viendo una película de imagen 
real o una animación hecha por orde- 
nador, nuestro cerebro interpreta como 
un movimiento fluido algo que en rea- 
lidad no es más que una secuencia de 
imágenes estáticas proyectadas una de- 
trás de otra. Esto se debe a que nuestro 
sistema nervioso no es lo bastante rá- 
pido como para advertir el engaño. 


Concretamente, para que percibamos 
esta sucesión de imágenes estáticas co- 
mo una animación fluida, se necesita, 
al menos, una velocidad de 24 frames o 
cuadros por segundo, aunque muchas 
animaciones hechas por ordenador sólo 
exhiben unos 15 o 12 frames por se- 
gundo. (Nota: es de suponer que un ex- 
traterrestre, con una potencia mental 
tan notable como la de 
vulcaniano Mr. Spock, 
necesitará, al menos, una 
tasa de 300 frames por 
segundo para percibir una 
animación fluida). 

Y ahora hagamos algu- 
nos números. Suponga- 
mos que queremos crear 
una animación que cons- 
te de unos 12 frames por 
segundo. Si deseamos 
generar una animación 
de un minuto de duración esto nos 
obligará a generar 12%60 = 720 esce- 
nas para montar la película. Suponien- 
do que estemos generando los frames a 
una resolución de 320*240 píxeles y 
asumiendo que utilicemos un formato 
donde se precise un byte por cada 
componente de color (por ejemplo, el 
TGA), nos dará como resultado una Ci- 
fra de 230410 bytes para cada frame 
(en realidad hace falta algo más para 
guardar la cabecera del fichero). Por 
tanto, si tenemos 720 archivos de este 
tipo, necesitaremos unos 158 Megas 
sólo para almacenar la secuencia de 
frames a partir de la cual se va a cons- 
truir la animación. Naturalmente esto 
no significa que dicha animación vaya 
a requerir la misma cantidad de me- 
moria. Los formatos que suelen em- 
plearse para almacenar las animacio- 
nes con las que vamos a trabajar 


Fichero de ejemplo Plotglt 


pueden ser el FLI, el FLC y el AVI, y 
todos ellos emplean sistemas para aho- 
rrar memoria (a costa de perder, más o 
menos, calidad gráfica). 

Casi siempre se suelen procesar to- 
dos los cuadros de la animación para 
crear una paleta común que permita 
emplear un número de colores menor. 
Además, suele utilizarse también la 
animación diferencial. Este sistema se 
basa en la suposición de que la mayoría 
de los píxeles de un frame van a con- 
servar su color con respecto al cuadro 
anterior, por lo que sólo será preciso al- 
macenar los cambios con respecto a la 
escena del frame anterior. Esto puede 
hacer que sea prácticamente imposible 
predecir el tamaño final de un fichero 
de animación. Para comprobar esto se 
generaron tres archivos FLC a partir de 
tres ejemplos incluidos con la beta de 
«POV 3.1». Ya se ha dicho antes que 


actualmente «POV» no genera ficheros 
FLI, FLC o AVI, así que se tuvo que re- 
currir a una utilidad extema para reali- 
zar el montaje de la animación. Así, 
con el ya viejo Dta se generaron los 
FLC correspondientes a las animacio- 
nes de ejemplo slinky, camera y boing 
(en el directorio animate). Y el resulta- 
do fue que la memoria requerida para 
las animaciones se quedó en el 20%, el 
10% y el 1% de lo demandado por sus 
secuencias de frames respectivas. 

¿Y en cuanto al tiempo? Tampoco es 
fácil de calcular. Supongamos que tar- 
damos tres minutos en generar uno de 
los frames de 320*240 del ejemplo an- 
terior de 720 TGA. Entonces podría- 
mos suponer que tardaríamos una me- 
dia de 3*720 minutos en generar todos 
los frames de la escena, es decir, unas 
36 horas. Pero realmente la cosa no es 
tan precisa. La animación puede estar 
compuesta por una serie de secuencias 
con planos diferentes y algunas de ellas 
pueden demandar mucho más tiempo 
de cálculo que otras. En este caso lo 
mejor será generar no una, sino varias 
animaciones —que serán montadas des- 
pués en una sola— y efectuar los cálcu- 
los de tiempo en función del frame ini- 
cial de cada secuencia. 


Por el momento estudiaremos cómo 
podemos manejar «POV» para crear 
las secuencias de frames a partir de las 
cuales se montarán las animaciones. 
Más adelante ya veremos qué utilida- 
des pueden emplearse para realizar los 
mencionados montajes. 


Conceptos básicos 
Antes de crear una animación de 
cualquier tipo habremos de contar con 


Fichero de ejemplo Reflect 


los personajes que van a intervenir en 
ella. Dichos personajes pueden ser mo- 
delos creados desde el mismo «POV» o 
modelos importados construidos desde 
otros programas. Sin embargo, antes 
incluso de disponer de los protago- 
nistas de la película, será conveniente 
contar con el guión de la misma. ¿Cuál 
es el plan? ¿Vamos a intentar narrar 
una historia por simple que sea? ¿O 
preferimos ilustrar una secuencia de 
efectos especiales? Sea cual sea la idea 
básica, como siempre será preferible 


utilizar papel y lápiz para asegurarnos 
de que lo planeado está lo suficiente- 
mente claro, ya que es mejor hallar los 
fallos en la fase de planificación que 
después, cuando hayamos generado 
200 o 400 frames inservibles. La ma- 
nera de preparar este guión dependerá 
un poco de cada autor. Quizá lo mejor 
sea preparar un guión muy esquemáti- 
co de la película. Dicho guión podría 


estar compuesto por apartados nume- 


Fichero de ejemplo L_0 


rados. siendo cada uno una descripción 
de un plano de cámara diferente al an- 
terior. Además, cada uno de estos apar- 
tados incluiría también la enumeración 
de los cambios operados en los objetos 
y en sus texturas, así como en las fuen- 
tes de luz. Hecho esto podríamos pre- 


parar un storyboard dibujando una se- 
rie de viñetas abocetadas para cada 
nuevo plano, sólo para aseguramos que 
tenemos una idea clara de cómo debe 
quedar visualmente la película. (Nota: 
no importa que no dibujemos demasia- 
do bien. Lo importante es que queden 
bien ilustradas las posiciones de la cá- 
mara y los objetos). 

El siguiente paso será la preparación 
de los frames propiamente dichos. En 
muchos programas la creación de los 
frames se construye mediante frames 
clave. Cada frame clave contiene una 
descripción precisa de todos los obje- 
tos de la escena en un momento deter- 
minado del tiempo; su posición, orien- 
tación, texturas, etc. El método consiste 
en definir una serie de frames clave en 
donde cada objeto cambie en el tiempo 
según nuestro criterio. Posteriormente, 
el propio programa, a una orden nues- 
tra, generará automáticamente todos 
los frames intermedios que deba haber 
entre los frames clave. A veces, cuando 
los cambios a definir sean 
muy sencillos, nos bastará 
con un par de frames clave 
para generar un montón de 
escenas intermedias. En otras 
ocasiones, en cambio, harán 
falta muchos más. La ventaja 
de este método, obviamente, 
radica en que es muy interac- 
tivo, ya que el usuario puede 
visualizar los cuadros clave 
cuando quiera (y por lo tanto 
puede hacerse una idea muy acertada 
de cómo va a ser aproximadamente la 
animación). Naturalmente se pueden 
cometer errores y puede hacerse nece- 
sario el insertar más frames clave o 
bien el tirarlos a todos a la basura y em- 
pezar de nuevo. Esta es la idea básica, 


Órdenes para «POV» relativas a la generación de secuencias de frames 


la misma orden en función 


la línea de comandos 


la orden en un fichero INI 


escritas en el archivo denomi- 


Initial Ecune=o +KFln Pone el frame inicial al valor n nado boingl -INI y añadirá 
Final_Frame=n +KFEn Pone el frame final al valor n e 

Initial_Clock=n.n +Kln.n Indica que el valor inicial del reloj sera n.n también las dos que hemos 
Final_Clock=n.n +KEFn.n Estipula que el valor final del reloj sera nn indicado como comandos de 


línea (con lo que las imáge- 
Figura 1 


aunque cada programa incorpora sus 
propios refinamientos a este método 
básico de frames clave. 

Explicado esto hay que aclarar que 
«POV» no funciona de esta manera. 
Con «POV», para cada animación in- 
dependiente (aunque luego ésta pueda 
formar parte de otra mayor) sólo existe 
un frame clave: el inicial. Para generar- 
lo escribiremos un fichero escénico uti- 
lizando el lenguaje de «POV», como lo 
haríamos para crear cualquier escena 
suelta. La diferencia estará en que aho- 
ra emplearemos una variable llamada 
clock que se utilizará como reloj de 
muchas o de todas las transformacio- 
nes descritas en la escena. 


Ordenes para generar 
animaciones 

Cuando invocamos a «POV» pasán- 
dole ciertos comandos. el programa en- 
tiende que debe generar no una única 
escena, sino una secuencia de ellas. Es- 
tos comandos se pueden impartir desde 
la línea de órdenes o bien escribiendo 
sentencias determinadas en un fichero 
de extensión INL. Los ficheros INI son 
archivos que guardan órdenes para 
«POV», y estas Órdenes se ejecutan 
cuando se invoca al programa pasándo- 
le el nombre de un archivo INI como 
parámetro (sin que dicho nombre sea 
precedido por ningún símbolo ni letra). 
Los ficheros .INI constituyen, pues, 
una alternativa al sistema de línea de 
comandos. ya que existe una sentencia 


INl equivalente para cada comando po- 
sible de la línea de órdenes. Sin embar- 
go, muchos pov-adeptos no utilizan fi- 
cheros INI. La razón de esto es que es 
superfluo aprender dos sistemas dife- 
rentes para conseguir un mismo resul- 
tado (y el sistema de la línea de órdenes 
es bastante más antiguo que el de los 
ficheros IND). Además, los comandos 
que podemos escribir en la línea de ór- 
denes son más cortos y más sencillos 
de memorizar que las sentencias de los 
archivos INI, como podéis comprobar 
echando un vistazo a la Figura 1. 

Con todo es conveniente que recor- 
déis lo que es un fichero .INI porque 
muchos de los ejemplos de «POV» 
—entre los que se hallan los de anima- 
ción- están almacenados en directorios 
donde también hay ficheros .INI utili- 
zados para generar dichos ejemplos. En 
estos casos es típico que el nombre del 
fichero .INI sea el mismo que el del 
ejemplo .pov para el cual se guardan 
las especificaciones. Así, si echáis un 
vistazo al directorio ““animatelboing”, 
veréis que hay dos ficheros llamados 
boingl.pov y boingl.INI. Editando el 
archivo .1N1, comprobaréis que éste 
imparte una serie de órdenes para 
«POV» pero no especifica la resolución 
de la imagen de salida. Por ello pode- 
mos renderizar boing!.pov, por ejem- 
plo, con la orden de línea del Cuadro 
1, lo que pasará a «POV» las Órdenes 


povray boingl +w320 +h240 
Cuadro 1 


nes tendrán una resolución de 
320*240 pixels). Por otro la- 
do, si estamos utilizando la versión 
«POV» para Windows, podremos ha- 
cer lo mismo editando el archivo INI y 
empleando la opción “Render/Edit Set- 
tings Render” para escribir las opcio- 
nes +w320 y h240 en el apartado “co- 
mand line options”. (Normalmente, 
con esta versión se utiliza esta opción o 
la de “render! Start Rendering” para 
renderizar el archivo .POV que está 
siendo editado, pero también podemos 
hacer lo mismo con los ficheros .IND. 
Bien, ahora que sabemos lo que son 
los ficheros .1NI y cómo emplearlos pa- 
ra generar los ejemplos de animación, 
podemos continuar estudiando las ór- 
denes de la Figura 1. En general, para 
ordenar la generación de una secuencia 
de imágenes bastará con emplear la or- 
den +KFF. Veamos un posible caso. 
Supongamos que hemos indicado a 
«POV>» que deseamos que el nombre 
del fichero de salida sea bola.tga. Pues 
bien, el comando +KFF100 ordenará al 
programa que renderice 100 escenas. 
El nombre de la primera será bo- 
1a001.tga y el de la última, bola100.tga. 
Esto sucede porque, por defecto, el va- 
lor para el frame inicial (KFD es 1. Si 
queremos que se generen 75 frames y 
que éstos vayan desde bola25.tga a bo- 
la100.tga, entonces deberemos añadir 
el comando +KFI25. (Nota: hay que te- 
ner cuidado con el nombre de la ani- 
mación porque el número a añadir pue- 
de sobreescribirse sobre éste. Por 
ejemplo, si ordenamos 100 frames so- 
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bre el nombre de salida mariposa.tga, 
entonces el primer fichero será ma- 
rip001.tga y el último marip100.tga). 

Sin embargo, cuando se emplea la 
orden +KFE. la generación de una serie 
de imágenes no es lo único que sucede. 
También ocurre que se activa una va- 
riable de coma flotante llamada clock, 
cuyo valor va cambiando, incremen- 
tándose automáticamente de manera 
proporcional para cada nuevo frame. 
Por defecto, el valor inicial de esta va- 
riable es O para la primera imagen de 
la serie y 1 para la última, indepen- 
dientemente de los valores dados a 
KFI y KFF. Así, y siguiendo con el 
ejemplo anterior, clock valdrá O para 
bola00!.tga, 0.001 para bola002.tga y 
1 para bola100.tga. Ahora bien, ¿para 
qué nos sirve la variable clock? 


La variable clock 

En «POV», el sistema para generar 
animación consiste en referenciar a la 
variable clock en las transformaciones 
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Fichero de ejemplo Boing1 


espaciales de los objetos. Supongamos, 
por ejemplo, que tenemos una esfera si- 
tuada en la posición X=0 y que de- 
seamos hacer una animación de 100 
frames en la que dicha esfera se despla- 
ce a la posición X=50. En tal caso em- 
plearíamos la orden representada en el 
Cuadro 2 dentro del fichero escénico: 


sphere(<0,0,0>,10 pigment[Red) 
translate<clock*50,0,0>) 
Cuadro 2 


En el primer frame, clock valdrá O y 
la esfera, por tanto, se renderizará en 
su posición de origen en el primer fra- 
me. En el siguiente, clock se incre- 
mentará al valor 0.001 y la esfera pa- 
sará a la posición 0.05, en el siguiente 
clock valdrá 0.002 y la esfera pasará 
a la posición 0.10, etcétera. Es fácil 
ver que la fórmula funciona correcta- 
mente porque el último valor de clock 
debe ser 1 y 1*50=50. 

Ahora supongamos que 100 frames 
nos parecen demasiados para represen- 


tar este sencillo movimiento y que que- 
remos generar la misma animación con 
50 frames. En este caso bastará con 
cambiar el valor de KFF por 50. En 
cuanto a la fórmula empleada en el 
ejemplo de antes, seguirá siendo válida 
porque clock se incrementa de O a 1 de 
manera proporcional al número de 
imágenes a generar. (Es decir, en el pri- 
mer frame, clock valdrá O, en el 25 val- 
drá 5 y en el último valdrá 1). Este sis- 
tema es muy cómodo porque podemos 
tirar pruebas de. por ejemplo, sólo 10 
frames de una secuencia para ver si és- 
ta es correcta y, luego, cuando haya- 
mos comprobado su validez, podemos 
volver a renderizar la secuencia orde- 
nando 50, 100 o 1000 frames. 

¿Y qué sucede si, por ejemplo, que- 
remos que las tgas a generar tengan nú- 
meros entre 25 y 125? En este caso uti- 
lizaríamos las órdenes de línea +KFI25 
y +KFF125, pero la fórmula para em- 
plear clock quedaría igual (si es que 
deseamos generar la misma secuencia 
del ejemplo anterior). 

Ahora veamos otro ejemplo sencillo. 
La misma esfera de antes tiene aplica- 
da una textura con el bitmap de la ima- 
gen de la tierra y deseamos que gire 
360 grados en torno a su eje produ- 
ciendo una animación compuesta por 
20 frames. Pues bien, en este caso utili- 
zaríamos la orden +KFF20 y escribi- 
ríamos la sentencia representada en el 
Cuadro 3 en el fichero escénico. 


sphere(<0,0,0>,10 texture[ mundo) 


rotate y*clock*360] 
Cuadro 3 


Por el momento se nos ha terminado 
el espacio permitido. Continuaremos el 
próximo mes. 


Masó 
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Nota importante. Podéis remitirnos vuestros trabajos o consultas, bien por carta a la dirección que 
figura en el sumario de PCmanía, o vía e-mail a rendermania.pcmaniaQ hobbypress.es 


Animaciones a lo grande 


A pesar de la advertencia | e — (Parte ID 


sobre los problemas que 


comporta la publicación de 
animaciones de gran tamaño, 


este mes y el siguiente r 


haremos una excepción con el 


fin de publicar algunos trabajos 
que nos fueron enviados antes 
de preveniros sobre el tema. 
Así, hallaréis aventuras estilo 
tron, cortos humorísticos, 


paseos por la nieve y otras 


Después de la paliza que los orcos les propinaron en el número 
17, Antonio Anton ha decidido enviar refuerzos a nuestros caba- 
cosas de interés. lleros. Para ello. Antonio ha creado un magnífico ejemplar de bár- 
baro y ha preparado también unas esrupendas escenas donde se 
ilustra cómo sus hordas se disponen a acudir a la batalla. (Todo ello 
ha sido renderizado desde «POV», utilizando mesh). Para crear el 
modelo del bárbaro (que podéis hallar junto a los incs correspon- 
dientes en el CD-ROM), Antonio ha empleado —aparte de «POV»- 
los programas «Spatct»», «Imagine 4» y «Hf-Lab». 

Gracias por tus elogios a las escenas del número 17, las tuyas 
también son estupendas y de hecho tu personaje nos ha gustado 
tanto que hemos decidido darle un bando propio. Habrá, pues. ba- 
tallas entre los caballeros del caos (nuestros), las hordas bárbaras 
(tuyas), la peste verde (los orcos) y las Evormigas. Por último, gra- 
cias por darnos a conocer la traducción del manual de «POV» que 
publicamos en este número (en tu directorio). 
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Presentamos nuestras más abyectas discul- 


pasa Juan Pacheco Guerreiro por haber deja- 


do pasar tanto tiempo antes de publicar sus ani- 


maciones. Además, la primera parte de este 


trabajo no aparece este mes sino que lo hizo en 


el número anterior, en el apartado de animacio- 


nes. En fin, 


publicamos 


aquí la segun- 


da parte del 


trabajo de 


Juan. En ella 


(como en la 


primera) se 


narran las 


aventuras de 


tres guerreros 


electrónicos 


en una rejilla 


de juegos y en 


lucha contra la 


tiranía 


cruel 


electrónica. 


El trabajo 


de Juan está 


fuertemente basado en Tron, y de hecho gran 


parte de la música de fondo y las voces están to- 
madas de este clásico de Disney. A pesar de la 
sencillez de la geometría (imprescindible para 
generar los frames con rapidez), la ambientación 
está muy bien lograda y algunas escenas (sobre 
todo en la segunda parte) son prácticamente 
idénticas a las de la película. La expresividad de 
los tres héroes es extraordinaria y sus movimien- 
tos, así como los de la cámara, están muy bien 
hechos, La animación, además, no es una mera 
sucesión de imágenes, sino una historia bastante 
bien articulada que tiene escenas verdaderamen- 
te memorables. (Nuestras favoritas son la perse- 
cución de los tanques por la rejilla y la lucha final 
contra el gigante). 

Sus únicos defectos radican en algunas escenas 
que quedan muy oscuras. Además, ambas partes 
“sólo” duran un total de unos 10u 11 minutos. 


Nos hemos sorprendido al leer 
la carta de Alfonso Garcia Or- 
das donde nos mencionaba que 


esta era la cuarta vez que envia- 


> — HZ bala animación que publicamos 
este mes aquí, y cuya elaboración data del 96, Está claro que han surgido 
problemas de algún tipo porque tu paquete de discos estaba encima de la 
pila y no hemos encontrado ningún otro paquete similarcon tu nombre. 
En cuanto a tu animación, construida con «3D Studio», nos ha pa- 
recido fantástica. Tu película recuerda, por su desarrollo y por los 
gags, a un corto de dibujos animados de la Warner. Los movimientos 
de los personajes están muy cuidados y resultan muy expresivos. 


¿Qué puede esperar quien envía una animación en 20 discos? Pues que al- 
gunos lleguen mal, claro. Esto es lo que ha sucedido con el trabajo de Sergio 
Ruiz Navarro, un amante de «3D Studio», «MAX» y «Rhino». Tan sólo ha 


sido posible rescatar la animación snow.fli (y poco más), donde disfrutare- 
mos con las acrobáticas evoluciones de un deportista virtual sobre la nieve. 


Excelente animación del personaje y de la cámara y buen efecto manual de la 


nieve despedida por la tabla. El único problema está en que el tamaño del su- 


sodicho chorro de 


nieve permanece 


constante incluso 


en los derrapes, pe- 


ro, Claro, esto no es 


precisamente fácil 
de hacer. Sergio, 
bravo por la anima- 
ción y por las esce- 
nas del coche. 


- 


- 


ISTAMARGO 
- "dd 


ye £ 


pre- 


gunta sí podemos enviarle los pri- 
meros 16 números de Renderma- 
nía. sin PCmanía. Tememos que 
no. Ten en cuenta que en cada PC- 
manía viene un número de Render- 
manía y no podemos extraer el su- 
plemento sin dejar incompleta la 
revista, Pero, de todos modos, para 
iniciarte con «POV» no necesitas 
todos los números publicados de 
Rendermanía. Procura leerte los 


publicados desde el 16. 


nos 
envía una animación para presentarnos 
a su grupo NeoDreams. Según afirma 
David. este grupo tiene en proyecto 
una animación en clave humorística de 
una batalla entre mechs que, calculan, 
ocupará unos 50 Megas comprimidos. 
Como estos autores saben lo difícil 
que nos sería publicar un trabajo de es- 
ta extensión. solicitan la creación de 
una sección fija o un concurso de ani- 


maciones. Se estudiará. 


tro amigo 


El récord absoluto en tiempo de espera para animaciones per- 


didas en pozos espacio-temporales se lo lleva la carta de nues- 


cuyo trabajo, dos anima- 


ciones creadas con «3D Studio 4», publicamos ahora. ¡Un año 


de retraso! Bueno. 
tu carta debió caer 
detrás de una es- 
tantería accidental- 
mente. Esperamos 
que todavía leas 
estas páginas y 
puedas aceptar 


nuestras disculpas. 


nos envía algunas ¡máge- 


nes creadas con «3D Studio 4» y pide crítica de dos 
de ellas. Pues bien, BarÚ queda bastante resultona 


salvo por la textura de la barra, que le da un relieve 


excesivo y las barras del techo que 
parecen excesivamente grandes. La 
puerta del bar también parece dema- 
srado pequeña. aunque esto podría 
deberse a que la posición de la cáma- 
ra no permite apreciar bien la geome- 
tría. De esta escena nos gusta el con- 
traste de colores, la ¡iluminación y las 
sombras resultantes. 

En cuanto a Estación, nos parece una 
escena excelente por las texturas y la 
iluminación. Lo único que no nos ha 


gustado es la forma en que ha queda- 


do la textura de la acera en el corte de ésta, ya que 
no está a la altura de todo lo demás. 
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nos envía unas interesantes 


escenas creadas con «3D 
Studio» entre las que des- 
taca ¿un alienígena? mon- 
tado en monopatín. Y res- 
pecto a la vieja controversia «POV» vs «3D Studio», 
también creemos que es demasiado simplista decir que un 
programa es mejor que el otro. Cada uno supera al otro en 


determinados puntos. Gracias por tu felicitación. tus esce- 


nas y tus mallas. 


nos envía una escena 
espacial realizada con el 
programa «POV» y otras en 
las que interviene un estupendo 

mech inspirado en un modelo de 
Battletech. Nuestro amigo Diego 
espera que su mech, realizado 
con <3D Studio», participe en la 
próxima escena de mechs. Puedes 


contar con ello, 


ha decidido tomar parte por el 
bando de las evormigas en las inminentes confrontaciones que 
tendrán lugar entre esta especie y todas las demás, en nuestro 
pequeño mundo medieval. Para ello, José ha enviado las mallas 
de un escarabajo. una mantis y una libélula. El escarabajo será 
utilizado como un elefante de guerra (por su tamaño), la mantis 
será utilizada para la “caballería” de las evormigas y la libélula 
será empleada para aumentar el radio de vuelo de las Evormi- 
gas. Esto quiere decir que los demás bandos (orcos, caballeros y 
bárbaros) pueden haber quedado en cierta inferioridad pues, 
aunque disponen de artillería, carecen de caballería y fuerzas 
aéreas veloces. ¡Hay que seguir con la carrera armamentística! 
En cuanto a las criaturas de José, las emplearemos en la próxi- 
ma batalla donde participen las evormigas, pero no publicare- 


mos las mallas puesto que así lo ha solicitado el autor. Gracias 


por tu ayuda a las fuerzas insectoides. 


